<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
        "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta name="GENERATOR" content="TtH 3.67">
 <style type="text/css"> div.p { margin-top: 7pt;}</style>
 <style type="text/css"><!--
 td div.comp { margin-top: -0.6ex; margin-bottom: -1ex;}
 td div.comb { margin-top: -0.6ex; margin-bottom: -.6ex;}
 td div.hrcomp { line-height: 0.9; margin-top: -0.8ex; margin-bottom: -1ex;}
 td div.norm {line-height:normal;}
 span.roman {font-family: serif; font-style: normal; font-weight: normal;} 
 span.overacc2 {position: relative;  left: .8em; top: -1.2ex;}
 span.overacc1 {position: relative;  left: .6em; top: -1.2ex;} --></style>
 

      
<title> Visual Workflow Editor</title>
</head>

<body> 
<h1 align="center">Visual Workflow Editor </h1>


 <h1><a name="tth_chAp3"></a>System Implementation</h1>
<a name="ch:implementation"></a>

<p>
This section gives an overview of the implementation details of this
project. The <a href="chapter1.html">architecture</a> had already been
defined and has been implemented following this <a
href="#ch:methodology">methodology</a>. The core task of the
implementation phase was the implementation of the Visual
Workflow Representation module. This module can be broke down into two
packages:
</p>

<ul>
<li> OGSA-DAI workflow model</li>

<li> Workflow Visual Editor</li>
</ul>

<p>
Both packages are divided into smaller sub-modules, according to
EMF and GMF specification.
</p>

<p>
A difference between the architectural specification and its
implementation is that modules with different functionality, but
similar implementation, have been packaged together. The two modules
that act as OGSA-DAI clients (the Resource and Activity Discovery and
the Workflow Execution) are considered to belong to a single package
called the <i>OGSA-DAI client</i>.
</p>

<p>
The following sections describe some implementation details of each
package, providing code snippets where necessary.
</p>


<h2><a name="tth_sEc1"></a>&nbsp;&nbsp;OGSA-DAI client</h2>

<p>
The implementation of this package consists of one single Java class,
that uses the OGSA-DAI Client Toolkit (<i>CTk</i>) functionalities to act as a client for
OGSA-DAI. The four public methods that are exposed to the other
packages are shown in the class diagram in <a
href="#fig:class_diagram_serverClient">Figure&nbsp;1</a>.
</p>

<div class="code">

</div>
<a name="tth_fIg1"></a>     
<center>    
<img src="gfx/class_diagram_serverClient.png" 
     alt="gfx/class_diagram_serverClient.png" />
<br/>    
Figure 1: ServerClient Class diagram
<a name="fig:class_diagram_serverClient"></a>
</center>


<p>
The Listing below shows the implementation of the workflow execution
method. From the code it's possible to notice that the method reads an
XML file containing the workflow definition from the file system. This
solution is inefficient, mainly because the XML document is already
loaded with the workflow diagram. It would be easy to add a new method
that accepts an XML Document object as parameter, but due to a problem
that is described in the <a
href="#sec:serialization">Section&nbsp;9</a> it has not been possible
to follow this solution.
</p>

<pre>
public RequestResource executeRequest(String docPath)
 	throws Exception {
 
 	String drerIDStr = "DataRequestExecutionResource";
 	ResourceID drerID = new ResourceID(drerIDStr);
 	RequestExecutionType execType = RequestExecutionType.SYNCHRONOUS;
 	
 	DataRequestExecutionResource drer = server
 		.getDataRequestExecutionResource(drerID);
 	DocumentWorkflow workflow = new DocumentWorkflow(docPath);
 	RequestResource request = null;
 	try {
 		request = drer.execute(workflow, execType);
 	} catch (RequestExecutionException e) {
 		System.out.println(e.getRequestResource().getRequestStatus());
 		throw e;
 	}
 	return request;
}
</pre>


<h2><a name="tth_sEc2"></a>&nbsp;&nbsp;Modelling the OGSA-DAI workflow</h2>

<p>
The MDA methodology requires a Platform Independent Model to be
constructed. This task is accomplished using the capability given by EMF
to generate models starting from an XML Schema definition. The XML
definition used to build the model is the one provided with the OGSA-DAI
extension pack 1. The definition consists of an XML Schema Definition
(XSD) file in which a workflow is defined in terms of XML Schema
elements.
</p>

<p>
The XSD shown in Listing&nbsp; has been imported as EMF model,
generating an <i>.ecore</i> file and a <i>.genmodel</i> file. The
ecore file describes the model itself, while the genmodel serves
as a decorator indicating some model properties such as the Java package
names, the serialisation form, etc.
</p>

<p>
**HERE I SHOULD PUT THE XSD**
</p>

<p>
The functional unit of model is the <i>ActivityType</i> element,
<a href="#fig:model_diagram_top">Figure&nbsp;2</a> shows how it has
been modelled. An ActivityType has three attributes (each one
corresponding to the EMF class <i>EAttribute</i>):
</p>

<ul>
<li> 
<i>instanceName</i>: name of the activity which is an arbitrary name
assigned by the user but it has to be unique within the scope of the
request.
</li>

<li> 
<i>resource</i>: target of the activity. It is obtained from the
OGSA-DAI service and refers to the resource that are deployed on the
service. Given that an activity may not be associated to a resource,
i.e. a transformation activity, the attribute is optional.
</li>

<li> 
<i>name</i>: of the activity on the OGSA-DAI server. It is obtained
from the OGSA-DAI service and depends on the target resource selected
for the activity. If no resource is selected, the service will return
a default activities list.
</li>
</ul>

<p>
An ActivityType <i>contains</i> one <i>InputsType</i> and one
<i>OuputsType</i>. Those classes are used to reference other input and
output objects. The containment feature is modelled using an EMF
<i>EReference</i>. An input in a OGSA-DAI workflows can be represented
by a data type, modeled by the class <i>DataType</i>, or by an
InputStream. InputStream means that the data that will be given as
input to the activity comes form a another activity, that uses a
OutputStream to send as output the data.
</p>

<a name="tth_fIg2"></a>     
<center>    
<img src="gfx/model_diagram_top.png" alt="gfx/model_diagram_top.png" />
<br/>
Figure 2: UML Class Diagram of the ActivityType element
<a name="fig:model_diagram_top"></a>
</center>

<p>
In the <a href="#fig:model_diagram_bottom">Figure&nbsp;3</a> is shown
the structure of a request. A request has a tree structure with
pipelines as leaves. The nodes of the tree are called workflows. A
workflow can either be a parallel (modelled as <i>ParallelType</i>), a
sequence (modelled as <i>SequenceType</i>) or a pipeline (modelled as
<i>PipelineType</i>) workflow. Parallel and sequence workflows may
contain any number of child workflows. A sequence indicates that its
child workflows are executed in sequence. A parallel indicates that
its child workflows are executed in parallel. There is exactly one top
level workflow. A pipeline contain only activities but no other
workflows.
</p>

<a name="tth_fIg3"></a>     
<center>    
<img src="gfx/model_diagram_bottom.png" alt="gfx/model_diagram_bottom.png" />
<br/>    
Figure 3: UML Class Diagram of the ActivityType element2
<a name="fig:model_diagram_bottom"></a>
</center>

<h3><a name="tth_sEc2.1"></a>Generated Code</h3>

<p>
Once the model has been designed using the EMF genmodel file it's
possible to generate the Platform Specific Model, and then the three
modules containing the code<a href="#tthFtNtAAD"
name="tthFrefAAD"><sup>3</sup></a>.  The generated code consist in:
</p>

<ol type="1">
<li> 
Model: provides Java interfaces and implementation classes for all the
classes in the model, plus a factory and package (meta-data)
implementation class. For each meta-model element there is an
interface and an implementation class generated.
</li>

<li> 
Adapters: generates implementation classes (called ItemProviders) that
adapt the model classes for editing and display.
</li>

<li> 
EMD.Edit: it contains a number of utilities for building editors like
standard table and property sheet views.
</li>
</ol>


<h3><a name="tth_sEc2.2"></a>Code customisation</h3>

<p>
The EMF aim is to generate automatically as much code as possible, but
sometimes for really domain specific problem, it has been required to
customise the generated code. According with the MVC patter the
EMF.Edit code, that in the project can be considered as a controller,
has no knowledge about the business layer, that in the project is
represented by the OGSA-DAI client. In order to implement one of the
functional requirements, the controller has to use the OGSA client to
query what activities and resources are available, and dispatch them
to the View. This behaviour cannot be modelled (and moreover it will
be against the MDA principles) and thus a customisation of the
generated code has been required. The <a
href="#fig:sequence_diagram_listres">Figure&nbsp;4</a> shows a
sequence diagram, illustrating the interaction between the
<i>ActivityTypeItemProvider</i> class and the ServerClient.
</p>

<a name="tth_fIg4"></a>
<center>
<img src="gfx/sequence_diagram_listres.png" 
     alt="gfx/sequence_diagram_listres.png" />
<br/>    
Figure 4: Interaction between ActivityTypeItemProvider and ServerClient
<a name="fig:sequence_diagram_listres"></a>
</center>


<h2><a name="tth_sEc3"></a>Building the Workflow Visual Editor</h2>
<a name="sec:gmf"></a>

<p>
To build the Workflow Visual Editor on top of the EMF ecore model,
there are a number of additional models that have to be defined. They
have already been described in the introduction section of the
previous chapter: the next sections will describe the steps to
generate the GMF diagram editor. The models to be defined are:
</p>

<ol type="1">
<li> 
<i>.gmfgraph</i>: A model that defines the graphical notation,
including shapes ,decorations, graphical nodes and connections.
</li>

<li> 
<i>.gmftool</i>: A model for the editor's palette and other tooling
definition.
</li>

<li> 
<i>.gmfmap</i>: A mapping model that binds gmfgraph and gmftool to the
ecore file. The two models defined above are technically (but not
conceptually) independent from the domain metamodel.
</li>
</ol>


<h3><a name="tth_sEc3.1"></a>GMF Graph definition</h3>

<p>
The graphical elements that are used to compose a workflow are
essentially:
</p>

<ul>
<li> 
Activity element: is the visual representation of the ActivityType element
</li>

<li> 
Workflow elements: the workflows elements to be defined are four
representing WorkflowType, PipelineType SequenceType and ParallelType
</li>

<li> 
Input and Output elements: this group of elements represent
InputsType, OutputsType, InputType, OutputType, InputStreamType,
InputLiteralType.
</li>

<li> 
Link element: is the visual representation of the link between an
InputStream and an OutputStream
</li>
</ul>


<a name="tth_fIg5"></a>
<center>    
<img src="gfx/screenshot_gmfgraph.png" alt="gfx/screenshot_gmfgraph.png" />
<br/>    
Figure 5: GMF Graph definition
<a name="fig:screenshot_gmfgraph"></a>
</center>


<p>
The <a href="#fig:screenshot_gmfgraph">Figure&nbsp;5</a> shows some
sections of the gmfgraph model: on the top is shown the set of figures
that are used to represent, graphically, the domain model elements.
Any sort of figure can be constructed with the available options by
adding them as a New Child to the present Figure. Looking at the
details about the Activity Figure, it's represented with a <i>rounded
rectangle</i> and is decorated with three attributes: RGB colour to
set the foreground, a layout definition and a label.  After that, all
the figures have been defined, they have to be linked with a GMF node:
this is useful to refer to the node, avoiding to reference the figure
that represent it, adding a level of indirection.  Two other important
elements that are shown in the Figure are the <i>Connection</i>
element, that represents a graphically connection between two nodes,
and the <i>Compartment</i> element. A compartment is a graphical
element that has no counterpart in the ecore model, and is useful to
contain other elements, providing feature such the possibility to be
collapsed and scroll bars to be navigated.
</p>

<h3><a name="tth_sEc3.2"></a>The Tool Model</h3>

<p>
The .gmftool model defines the set of palette entries. A palette is a
set of buttons on the right of an editor that allows to add model
elements to the domain model instance. The Figure&nbsp;<a
href="#fig:screenshot_gmftool">6a</a> shows the elements that are
defined in the model, and Figure&nbsp;<a
href="#fig:screenshot_palette">6b</a> shows how the palette is
displayed the visual editor.
</p>

<a name="tth_fIg6"></a>     
<center>            
<img src="gfx/screenshot_gmftool.png" alt="gfx/screenshot_gmftool.png" />
<br/>
Figure 6: Screenshot showing the Tool definition and how this
definition is represented in the Visual Workflow Editor
</center>


<h3><a name="tth_sEc3.3"></a>The Mapping Model</h3>

<p>
This is the most complex model: here the domain, the graphical
definition, and the tooling definition, are bounded together in a
model that will be used to generate the <i>.gmfgen</i> model. The
<a href="#fig:screenshot_gmfmap">Figure&nbsp;7</a> shows some sections
of the mapping model.
</p>

<a name="tth_fIg7"></a>
<center>
<img src="gfx/screenshot_gmfmap.png" alt="gfx/screenshot_gmfmap.png" />
<br/> 
Figure 7: GMF Graph definition
<a name="fig:screenshot_gmfmap"></a>
</center>


<p>
In the figure is possible to recognise several important elements of
the model: first of all this model establishes the hierarchy that will
be used in diagram. The first level of the hierarchy is represented by
elements classified as <i>Top Node Reference</i>.In this specific
mapping model, they represents graphically the three different type of
workflows.
</p>

<p>
Another detail that is shown in the figure is how the leafs of the
workflow, defined in the gmfgraph model as plain elements and with no
relationship with other elements, are nested in a hierarchy that
reflects the way the workflow will be composed.
</p>

<p>
On the bottom part of the Figure, are shown the properties of a mapped
element. A node mapping an Activity is characterised by a <i>Domain
meta Information</i> equal to ActivityType, by a <i>Diagram
Node</i>(the actual element displayed on the diagram) equal to Node
Activity and a Tool.
</p>

<h3><a name="tth_sEc3.4"></a>Generated Code</h3>

<p>
Using the mapping model, is possible to generate the GMF generator
model, that is the last step in the process of defining a GMF
editor. This last model refers to the process of generating a model,
giving the possibility to tune the code generation process. It will
not add new elements to the diagram, but just decorate it.
</p>

<p>
The amount Java classes generated running the model, is very big and
describing them will be beyond the scope of the thesis (and probably
impossible).
</p>

 <h2><a name="tth_sEc4"></a>Diagram Serialisation and Validation</h2>
<a name="sec:serialization"></a>

<h3><a name="tth_sEc4.1"></a>Diagram Serialisation</h3>

<p>
The diagram serialisation feature comes "for free" with the decision
of using EMF to design the model. The possibility to persist models
defined with the ecore language, allows EMF to be integrated it with
other applications, and it's one of the most powerful EMF features.
</p>

<p>
EMF ecore models are persisted using XMI language. The EMF framework
already provides a default XMI serializer that can be used to persist
user defined models. For the purpose of the project, XMI serialisation
is not a good solution, considering that the OGSA-DAI document client,
accepts workflow define in a XML format. Above the default
serialisation support, EMF allows to serialise model in any persistant
format. In this case it would be necessary to write a serializer for
the model, but again, EMF provides a serializator to persist objects,
as XML document conforming to a XSD schema.
</p>

<p>
Once the EMF model has been generated, the class that is in charge of
serializing and de-serializing the model
is <i>ModelResourceFactory</i>, and is automatically used by the GMF
framework to handle the "Save" and "Open" actions.
</p>

<p>
To fulfil one of the requirements it has been necessary to add custom
code, in order to obtain a representation of the workflow and execute
it. The first approach that has been investigated was to use an in
memory representation, avoiding to serialise the the model on the
file-system.
</p>

<p>
The code in Listing shows how the ModelResourceImpl class is used to
serialise the diagram, on a XML document.  Although the proposed
solution is really efficient, it presents a conflict between the
different <i>xerces</i> libraries that are used by OGSA-DAI and by
EMF.  A workaround to this problem is presented by the code in
Listing&nbsp;, that uses the ModelResourceImpl to serialize the model
on a temporary file created using the URI associated to the model.
</p>

<h3><a name="tth_sEc4.2"></a>Diagram Validation</h3>
<a name="sec:validation"></a>

<p>
One of the non-user requirements identified in the first section of
the project, is that the diagram that is produced by the editor has to
be <i>valid</i>.  Adopting EMF as modelling language enabled the
possibility to implement the validation using the <i>EMFT Validation
Framework</i>. The EMFT Validation framework provides a means to
ensure the well-formedness of EMF models. The EMF generated code, uses
the Validation framework, to build a basic validator, that checks the
in memory model against the ecore definition of the model, and this
validator is enough to fulfil the non-user requirement.
</p>

<p>
In order to use the validation provided by EMF, the gmfgen model has
to be modified in the way shown in the Figure&nbsp;<a
href="#fig:validation_option">8</a>
</p>


<a name="tth_fIg8"></a>     
<center>    
<img src="gfx/validation_option.png" alt="gfx/validation_option.png" />
<br/>   
Figure 8: Options to enable the model validation
<a name="fig:validation_option"></a>
</center>


<p>
The code in Listing&nbsp; shows how to force the validation of a
request, before its submission to the OGSA-DAI service. If the model
is not valid, it would be possible to iterate through the errors
showing in a dialog-window. Moreover the GMF framework is in charge on
highlighting the elements of the diagram that are not didn't passed
the validation.
</p>

</body>
</html>